fix(host): refuse an ask_user card outside two to four answers (#2771) - #2772

Fixes #2771

Owner: Dev-3
Reviewer: Birfy
Written-by: Dev-3
Bot: Dev-3
Claim-Id: 64cc0994fa0b439f80667b03c5b45fd2
Base: f2ef4df
Risk tier: T1

The defect

core/src/host/tools.js declared the count and then did something else with it: the options parameter said Two to four answers (:626), the normaliser dropped empty labels, .slice(0, 6) cut whatever was left, and the only size check was options.length === 0 (:654). Measured on the live base f2ef4dfa with the fixture below — call the registered ask_user tool, then read state.questions back through /api/bot state:

ONE   -> {"returned":"The card is on screen; the user's answer arrives as their next message.","stored":["A"]}
FIVE  -> {"returned":"The card is on screen; the user's answer arrives as their next message.","stored":["A","B","C","D","E"]}
SEVEN -> {"returned":"The card is on screen; the user's answer arrives as their next message.","stored":["A","B","C","D","E","F"]}

A one-option card is stored and its single option comes back as the user's answer; a seventh option reaches nothing and the tool still answers that the card is on screen. The group path askInGroup (:681) receives the same array, so a question handed out from a group behaved identically.

What changed

• core/src/host/tools.js :646-655 — the normalisation and the empty-label filter stay; .slice(0, 6) and the length === 0 refusal are replaced by one check on the labels that survived the filter, in the slot the old refusal held (before the handedFromGroup branch, so askInGroup inherits it). Fewer than two or more than four returns Give two to four answers. and writes no card; two to four options store exactly what they stored before.
• core/test/questions.test.js — five cases on the existing start() fixture: one option refused, six refused, seven refused (not cut to six), two and four unchanged to the byte (the answer string plus the stored card with its identity fields removed), and five given with two blank labels counted as three and accepted.
• changelog.d/2771-ask-user-two-to-four-answers.fixed.md — the user-visible entry.
• patches/ds-bot/0002-flybot-api-host.patch and patches/ds-bot/topics.json — regenerated. test/questions.test.js is an upstream file, so its first edit needed a topic; it joins 0002, which already owns src/host/tools.js, and generate rewrote that patch. The test file is not in files/.

Read paths are untouched: cardText, the questions renderer, answer-question and the inbox still read and answer a stored one-option card, and the fixtures that model those legacy cards are unchanged.

Verification at the tip

Tip SHA: 75e5f61235e6f0d378d59486dc093aeba6fc1354 (tree e25b86c8ab3823b2d6cc88d86aa12a982a4d5038)

Ran:

• cd core && node --import ./test/harness-resolve.mjs --test --test-timeout=120000 test/questions.test.js → 7 tests / 7 pass / 0 fail, twice in a row, same shape.
• cd core && node --import ./test/harness-resolve.mjs --test --test-concurrency=4 "test/*.test.js" → 2571 tests / 2481 pass / 90 fail. The clean base f2ef4dfa in the same clone gives 2566 / 2476 / 90, and the failing-file set is identical (diff clean): those 90 files cannot load esbuild/jsdom in this fresh clone (no core/node_modules, registry 404s). Every test that loads is unchanged apart from the five new cases.
• node core/scripts/check-arch-docs.mjs → arch-docs: OK (5 changed file(s)); the branch commit carries the Docs-not-needed: trailer.
• node scripts/ds-bot-patches.mjs check → ok core/ equals ds-bot/ + patches/ds-bot/.
• node .github/scripts/changelog.mjs check → 17 fragments well formed.
• oxlint -c core/.oxlintrc.json core/src/host/tools.js core/test/questions.test.js → 0 errors, 2 warnings, both the pre-existing no-control-regex at tools.js:85.

Not run (and why):

• root npm run verify — its npm ci cannot reach a registry on this box (404 on the configured mirror) and this clone has no core/node_modules, so the harness comes from DSH_HARNESS and the steps were run individually.
• node core/scripts/build-client.mjs --check — needs the same missing esbuild; this diff touches neither core/src/client/ nor core/client.js.
• the smoke test (dev/bench.sh) — needs the same install; this diff changes one refusal in a tool handler, not a route, turn or delivery path.

Red first

On the live base f2ef4dfa with only the test file added (source change reverted), node --test test/questions.test.js fails exactly three of the five new cases, twice in a row with the same shape:

not ok 3 - #2771: one option is refused with the rule and stores no card
  + actual - expected
  + "The card is on screen; the user's answer arrives as their next message."
  - 'Give two to four answers.'
  expected: 'Give two to four answers.'
  actual: "The card is on screen; the user's answer arrives as their next message."

not ok 4 - #2771: six options are refused with the rule and store no card    (same shape)
not ok 5 - #2771: seven options are refused, never cut to six                (same shape)

# tests 7
# pass 4
# fail 3

The two guards stay green on that base — the two-and-four card is already byte-identical today, and five given with two blanks is already three buttons — which is what makes them controls rather than two more reds.

Checkpoint

{
  "pr": 2772,
  "claim": "Dev-3",
  "issue": 2771,
  "summary": "The card's own description said two to four answers while the host sliced the labels to six and refused only the empty array, so a one-option card was stored and its single option came back as the user's answer, and a seventh option vanished with no word. Both ends are now refused with one sentence naming the rule, counted on the labels that survived the empty-label filter, so five given with two blanks stays a three-button card. Two to four options keep the card and the answer string byte for byte, and no read path or stored legacy card is touched. Five cases cover it.",
  "files": ["core/src/host/tools.js", "core/test/questions.test.js", "changelog.d/2771-ask-user-two-to-four-answers.fixed.md", "patches/ds-bot/0002-flybot-api-host.patch", "patches/ds-bot/topics.json"],
  "checks": { "ran": "cd core && node --import ./test/harness-resolve.mjs --test --test-timeout=120000 test/questions.test.js", "result": "green", "at": "75e5f61235e6f0d378d59486dc093aeba6fc1354" },
  "next": "none — ready for review"
}